home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9610 / 000080_owner-urn-ietf _Wed Oct 23 08:17:55 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  3KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA24249 for urn-ietf-out; Wed, 23 Oct 1996 08:17:55 -0400
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id IAA24243 for <urn-ietf@services.bunyip.com>; Wed, 23 Oct 1996 08:17:53 -0400
  3. From: jayhawk@ds.internic.net
  4. Received: from cagw1.att.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  5.         id AA15181  (mail destined for urn-ietf@services.bunyip.com); Wed, 23 Oct 96 08:17:51 -0400
  6. Received: from qsun.ho.att.com by caig1.att.att.com (SMI-8.6/EMS-1.2 sol2)
  7.     id IAA25797; Wed, 23 Oct 1996 08:14:21 -0400
  8. Received: from qsun2.ho.att.com.qsun2 by qsun.ho.att.com (4.1/EMS-1.1.1 SunOS)
  9.     id AA03918; Wed, 23 Oct 96 08:17:38 EDT
  10. Received: from rickslap.ho.att.com by qsun2.ho.att.com.qsun2 (5.x/EMS-1.2 sol2)
  11.     id AA05666; Wed, 23 Oct 1996 08:16:32 -0400
  12. Message-Id: <9610231216.AA05666@qsun2.ho.att.com.qsun2>
  13. Original-From: "Ryan Moats" <jayhawk@ds.internic.net>
  14. To: "URN mailing list" <urn-ietf@bunyip.com>
  15. Date: Tue, 22 Oct 96 18:50:53 
  16. Priority: Normal
  17. X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE
  18. Mime-Version: 1.0
  19. Content-Type: text/plain; charset="us-ascii"
  20. Content-Transfer-Encoding: 7bit
  21. Subject: Re: [URN] Pre release of URN Syntax document....
  22. Sender: owner-urn-ietf@services.bunyip.com
  23. Precedence: bulk
  24. Reply-To: jayhawk@ds.internic.net
  25. Errors-To: owner-urn-ietf@bunyip.com
  26.  
  27. On Tue, 22 Oct 96 12:27:42, Ryan Moats wrote:
  28.  
  29. >Hmmm, that's an interesting concept.  I have been considering 
  30. >"lexical equivalence" at the client and what you call "functionally equivalent"
  31. >at the server to be the same thing.  Basically, my definition of lexical equivalence
  32. >is that "two URNs are considered lexical equivalent at a machine if that machine
  33. >can determine unequivically USING ONLY LOCAL KNOWLEDGE that the two
  34. >URNs will return in the same resource."
  35. >
  36. >(Of course, I can change this given a good enough reason).
  37. >
  38. >Thus, Ian's example above (with/without urn:) is one where the two URN's
  39. >are lexically equivalent at both a client and a URN resolver.  However,
  40. >Patrik's example is one where the two URN's are not lexically equivalent
  41. >at a client but would be lexically equivalent at a URN resolver.
  42. >
  43. >The bottom line is that I view lexical equivalence as a local phenomenom, rather
  44. >than a global one.  It dawns on me that I should probably add words to that affect
  45. >(and possibly use these examples to highlight this) in the draft.
  46. >
  47.  
  48. Ok.  Based on all the discussion, I will add some text to the lexical
  49. equivalence section that discusses the fact that lexical equivalence
  50. is a local phenomenon. (Amazing what happens when you are on a plane!)
  51.  
  52. Ryan
  53.